Mobile applications (applications) are generally classified as one of native, web, and hybrid. A native application is written in a native programming language for a specific mobile device platform and is executable only on the particular operating system (e.g., iOS, ANDROID, WINDOWS, etc.) associated with the platform. A native application can access the available Application Programming Interface (APIs) of the particular operating system (OS) and can access the mobile device's native platform features (e.g., camera, compass, GPS, etc.). However, a native application written for one mobile platform cannot be used on another, different mobile platform.
A web application is written in a web content language (e.g., HTML5, CSS3, JAVASCRIPT) and is accessed through the mobile device's web browser. Specifically, a web application runs within the mobile device's web browser instead of being executed directly by the OS. In this manner, a web application may be deployed to and run on different mobile device platforms. A hybrid application is built using web application content (e.g., HTML5, CSS3, JAVASCRIPT) that is wrapped in a platform specific container that provides limited access to native platform features.
It is common for a mobile application to be updated after it has initially been installed on a mobile device. An update may occur, for example, when the developer of the application makes a change to the user interface (UI) and/or logic within the code of the application. Updating a natively rendered application, though, requires the developer to update the entire application, and requires the user to download the entire updated application (e.g., from an app store) and re-install the updated application on their device. Essentially, the update is a complete, stand-alone application that takes the place of the previously installed application. In some cases, updating a native application can be a large operation since the entire application must be updated, downloaded, and re-installed. Moreover, the developer must update the different native applications for each different platform, which can also be very time consuming.
Developers that leverage hybrid applications (e.g., PHONEGAP, etc.) can create updates and send the updated code (e.g., HTML5, CSS3, JAVASCRIPT) to the mobile device via web server. For example, hybrid application developers can create an application that can be updated via an HTML5 manifest file across multiple platforms. An advantage of hybrid applications is that a developer can perform a user experience (UX) update on the device in a simpler manner than is required for updating native applications. However, a disadvantage of hybrid applications is that they lack the native UX preferred by end users of the mobile devices. Specifically, a hybrid application is not rendered natively; instead, a hybrid application relies on HTML5 and CSS to do the styling, and this type of rendering is not as flashy, smooth, or consistent as a natively rendered application.
Hence there exists a problem in that end users prefer the UX provided by a natively rendered application compared to that of a hybrid application, but updating a native application is more time consuming (for both the developer and the end user) than updating a hybrid application. Further, there exists a problem that native applications cannot be built in a modular fashion to quickly enable and disable features without applying an update to an app store, which requires a full update of the native application.
In-application purchases (also called in-app purchases) are another area in which natively rendered applications suffer from a lack of modularity. An in-app purchase is a way for a user to access special content or features in the application. Typically, the user provides payment to the application owner, and the application owner unlocks the special content or features in the application on the user's device. For native applications, the logic that defines the special content or features is contained (i.e., pre-installed) in the application when the application is initially downloaded and installed on the mobile device, and is merely unlocked (made available to the user) when the user makes the in-app purchase. This disadvantageously bloats the size of applications since the applications are pre-configured to contain in-app purchase logic that may not ever be purchased by the user.